Process management

ABSTRACT

The invention concerns a method for modeling, documenting and validating a system, preferably a company, comprising the following steps: Providing one or more sensors in a system, defining data to be recorded, parameterizing the data to be recorded, transforming the parameterized data to objects with parameters, linking the parameters of the objects by standardized relationships, checking and, if required, completing or modifying the recorded objects and their parameters, recording the parameterized data by means of the sensors, standardized analysis of the relationships of the objects, outputting the results of the standardized analysis in printed or in electronic form. Said steps are repeated at time intervals.

[0001] The invention lies in the field of process management, inparticular the dynamic process management by means of computer programsand sensors for the recording, modeling, documentation and validation ofcomplex processes and systems according to the preamble of theindependent claim.

[0002] In complex situations, processes and systems that comprise amultitude of interrelated parameters, it is very difficult to predictthe influence of changes to single parameters on the behavior of thetotal system. For example, when leading an enterprise, or whenorganizing large projects, taking decisions is a problem. Since thenumber of control parameters increases with the size of an enterprise ora project, the control variables often cannot be viewed as a whole.Therefore, it is very difficult to distinguish relevant factors fromirrelevant ones, to weigh them and to analyze them in context. For theabove reasons, decisions on a management level are nowadays often takenarbitrarily. A further problem lies in the fact that influencingparameters cannot be recorded objectively. Due to changing circumstancesand given facts, and due to lack of standardization, influences areappraised and interpreted differently. This constitutes a furtherproblem in decision taking, which requires a solution.

[0003] A standardized recording of relevant influencing parameters,their qualification and analysis is nowadays practically impossible, orinvolves a very large amount of time and use of resources. A dynamicrecording and analysis of a multitude of measurements fails due to theabovementioned problems, the complexity, the quality and consistency ofthe relevant information.

[0004] It is the object of the invention to show a method that permits astandardized recording, analysis, checking and representation of complexsystems and processes.

[0005] The implementation of the invention preferably is done in theform of one or more computer programs and by means of associated,respectively functionally related sensors. The inventive method can beused for the control of all aspects in a complex system, in particularan enterprise. The goal consists in recording and representing theprocesses and actions in the system considered and in placing them inrelation to one another. By the use of standardized processes andalgorithms in the creation of models and their verification, for exampleby comparison with alternative models, a dynamic image is generated,which represents the processes in terms of their relevant parameters. Bya formulation by means of a meta-model, abstract processes can berepresented in a simplified manner. By the construction as a framework,the scalability is ensured as well.

[0006] In order to assist the appreciation of the invention, acockpit/aircraft simulator shall serve as a practical example. In asimplified view, the invention is based on the same principles as theinstrumentation of a cockpit/aircraft simulator. The pilot can controland supervise everything, but is not provided with unnecessaryinformation that he does not need. The pilot nevertheless has access toall information to every degree of detail, if he needs it. Thus, undernormal circumstances, the pilot can safely steer the aircraft with asmall amount of relevant information, instruments and manual controls.He can, in the plane simulator, go through strategies, work outvariations, test behavior and perform simulations and verify possibleeffects of them.

[0007] According to a simplified view, the invention comprisesessentially three parts. These parts can be applied individually or as acomplete package. The first part is a scaleable software package that isconfigured individually according to the wishes of the operator of acomplex system. A second part is a model for proceeding that ispragmatic and oriented according to practice and is a furtherdevelopment of a known model for proceeding called “OOW” (ObjectOriented Way), which is described in the book “Der objektorientierteWeg” (ISBN 3-9521597-0-0) by the authors Roland Pulfer and Urs Schmid. Athird part comprises a normalized procedure which helps a user to reachstandardized results at a fixed date and with a defined effort.

[0008] The invention can comprise a so-called electronic adviser. Thiselectronic adviser, in simple terms, is an automated version of aclassical adviser. This electronic adviser knows about reference models,can accept information and propose alternative solution scenarios. Theelectronic adviser helps, on the one hand, to show the interrelations ina complex system and to make them transparent, on the other hand hehelps to filter out information that is not required at the moment.Preferably, all affected and participating sensors, control variablesand control locations should be quickly reachable, such that the processor processes can be influenced and optimized. This should support theinformation flow in an optimal manner. The affected and participatingsensors, control variables and control locations may not be flooded withirrelevant information. In the following, the significance of anelectronic adviser is explained in terms of an enterprise. In the caseof an enterprise, the electronic adviser should, whenever possible,support a conditional exchange and comparison (bench-marking) betweenenterprises on a neutral platform. Since many enterprises that are busywith largely different goods and services comprise similar internalstructures and process sequences, a comparison between a process modelfrom one enterprise with a process model of another enterprise doesindeed make sense. By means of a standardized approach, the models canbe interchanged, or traded, respectively. The motivation in offeringsuch a electronic and personal assistant and adviser follows, forexample, from the fusion of internal and external advisors. Manycompanies have employees that have worked as advisors for many years andhave a huge knowledge. This results in making external advisorsincreasingly unnecessary. A disadvantage of external advisors lies inthat it takes them far too long to work out well-founded know-how aboutimportant internal processes.

[0009] The invention wants, on the one hand, to support the innovation,the engineering, the project management and the implementation of goals,and, on the other hand, help to control the activities of an enterprise.The cockpit/flight simulator for the entrepreneur is a goodrepresentation of the inventive idea. A complex system such as e.g. anenterprise must be viewed and led as a whole and it should be possibleto perform checks already on a model basis. In order not to have thecomplexity of the problems hinder the manager of an enterprise in hiswork, certain information, in analogy to a cockpit/flight simulator witha pilot sitting in it, must be only around at a certain time and in acertain level of detail. During normal operation the pilot must onlyobserve and operate a few important instruments and visualizations. Whenan irregularity occurs, he must be able to reach (“drill down”procedures) any detail information, in order to support his actions. Heis presented with scenarios, alternatives are computed and their effectsare shown.

[0010] The invention is more closely explained on the basis of thesubsequent figures. They show schematically and strongly simplified:

[0011]FIG. 1 process sequences in a complex system;

[0012]FIG. 2 a supervision of processes with parameters according toFIG. 1;

[0013]FIG. 3 an overview over sensors and their arrangement;

[0014]FIG. 4 a server based application;

[0015]FIG. 5 connection with a knowledge database;

[0016]FIG. 6 processing of information;

[0017]FIG. 7 a possible basic structure;

[0018]FIG. 8 key results in a cube representation;

[0019]FIG. 9 work products on different meta layers;

[0020]FIG. 10 the dimensions used, in a simplified representation;

[0021]FIG. 11 a separation of strategies and goals;

[0022]FIG. 12 the modeling of requirements;

[0023]FIG. 13 a product model;

[0024]FIG. 14 a possible project management;

[0025]FIG. 15 a possible form of quality management;

[0026]FIG. 16 a possible form of risk management;

[0027]FIG. 17 dependencies that occur when creating models;

[0028]FIG. 18 a comparison between work products and products;

[0029]FIG. 19 an analysis of effects;

[0030]FIG. 20 risks and their interrelationships;

[0031]FIG. 21 a generation of scenarios and variants;

[0032]FIG. 22 a possible form of cost management;

[0033]FIG. 23 the relations between different systems;

[0034]FIG. 24 a risk management and the computation algorithms usedtherein;

[0035]FIG. 25 a dependency between multiple processes;

[0036]FIG. 26, 27 a reference model, and a reference model process,respectively.

[0037]FIG. 1 schematically shows processes as they may arise in acomplex system, e.g. an enterprise. The already mentioned comparison toa cockpit/flight simulator is visualized in FIG. 1 in another manner.This overview only shows a few of the most important foundations of theframework that may be extended arbitrarily.

[0038] For a target audience 1, strategies 2, requirements 3, processes4, process support 5 (infrastructure, software, organization, standardproducts) business value chains 6, products 7, their cross-linking anddependencies 8 are recorded, modeled, documented and validated. Further,if necessary, a risk management 9 and quality management 10 aresupported.

[0039] The models already mentioned are static views and refer to aparticular point in time (slot). For this point in time, all goals,definitions, descriptions, rules, exceptions, states and behavior aredescribed. The change over time is determined by means of the changebetween two points in time (slots). By comparing and merging by means ofCompare & Merge algorithms, a project portfolio (need for action) isdetermined. A list of all changes can subsequently be used for thedefinition of projects 12. These activities all are accompanied by theapproach by means of result lists, methods and techniques, check listsetc.

[0040]FIG. 2 schematically shows a supervision of processes andparameters according to FIG. 1. In order to create a sustainable benefitof an engineering according to FIG. 1 in an enterprise, sensors 13 oradapters 14 are installed at defined locations in an enterprise. Thesesensors 13 can operate manually or electronically. The sensors 13 serveto sample relevant information actively or passively and to report it tothe process supervision 15. For this purpose, threshold values or limitvalues are defined.

[0041] With the collected information, based on the configuration of theprocess supervision, actions can be initiated. The distribution ofinformation can be accomplished in a conventional manner e.g. by meansof paper 16 or in another manner, e.g. electronically or by usingexisting networks (e.g. cell phone network). Depending on settings andlimit values an action is initiated, e.g. an SMS, a sending of documentsby e-mail, a transfer of information to a mobile device, e.g. palmtop 17or portable computer 18, or a voice message is transmitted by phone. Ofcourse it must be possible to act and react, from the outside, accordingto the situation. For example, it must be possible to change thresholdvalues, parameters and configurations. These changes can be realizedmanually or electronically (e.g. through a mobile device). If required,it therefore is possible, largely independent on location, to acquireand request all important information and to react accordingly.

[0042]FIG. 3 schematically shows an overview over sensors and theirarrangement in a complex system.

[0043] Sensors 13 are preferably inserted in the form of softwareproducts into a business. Other kinds of sensors (e.g. embedded systems)are possible. The invention in addition allows to realize a passive andactive database query or store procedure. Furthermore, if the needoccurs, the possibility exists to analyze online movements on shares orfolders, in order to, for example, incorporate current data that aremade available through flat-file. Thus, for the first time thepossibility exists to automatically supervise and control changes ofmodel information or performance figures. Based on these currentperformance figures and model information, information from the runningoperation can bring massive facilitation for the modeling of furthertarget states. This necessitates, however, that after the engineering abusiness model for supervision and control of the running operation isgenerated from the engineering content.

[0044]FIG. 4 schematically shows the use of a server. An aspect of theinvention consists in making available all relevant fundamentals througha server, for example over the internet. The entire software isinstalled on this server. In this way, installing the software in theenterprise itself can be avoided. Furthermore, with a server basedapplication it is possible to directly generate applications andworkflows. These generated applications can also be made available forthe business directly on this platform. If someone does not wish to runapplications or models on this platform, he can download them aftertheir generation. A server based installation (ASP) should, whenrequired, also be used for comparison with others (benchmarking). Thisis done by the offering of comparison models that are deposited in adata base (repository). As further steps, customers or guests shall beable to offer their optimal solution (“best practice”) for sale toothers, or may download such patterns from others. As the lastfunctionality defined till today, models shall be loadable on theplatform for only the purpose of quality assurance. With the ASPversion, a further step is taken in the direction of an electronicalengineer/advisor. Over such a platform that can simultaneously offer atelephone advice center (call center) and/or a forum (chat, FAQ, newsgroup), without further effort, manually, human generated results forcompleting the available information can be made available. With thisfunctionality, the first version of an electronic or anonymousengineer/consultant is made available.

[0045]FIG. 5 shows a connection with a knowledge database 51. Theinvention allows to be connected with a knowledge management system.This connection allows the navigation and the access to information fora larger target audience. With simple search terms, it informationshould be able to be queried and modeled. Just the continuous processimprovement and the quality of documentation should be increased by thisfunctionality.

[0046]FIG. 6 shows, in a simplified representation, the processing ofinformation. The processing of information as a rule is done accordingto an input-based meta-model which, by means of mathematical functionsand based on pre-adjusted or configured parameters, makes available asoutput models, files, data, graphic representations and documents. Inthe left half of the image, the input data are shown. They are based onsensors or on other sources. As other sources, portable devices (mobilephones), databases, persons etc. come into question. On the right handside, the output variables are shown schematically. They areintermediate results, results, information for databases, reports andflow diagrams.

[0047]FIG. 7 schematically shows the basic structure of the method. Thebasic structure preferably is based on object oriented concepts.Therefore, the implementation happens by means of a suitable programminglanguage such as e.g. Java. The consequently applied concepts of objectorientation in the defined results (e.g. process, business value chain,product et.) are essential. Next to object oriented concepts (e.g.encapsulation, inheritance, object, class, etc.), also the orientationtowards practice (e.g. reduction of complexity), the re-use, pragmatism(transparency, consistency) and cross linking are to be mentioned.

[0048] The basis excels especially in that with the inventive tool notonly models can be modeled and documented, but also that all models canbe validated. Depending on their degree of completeness, models may beprovided with operative information (online) or compared (ASP,benchmarking).

[0049]FIG. 8 schematically shows, by means of cubes 81, 82, key resultsat different points in time. These key results and their cross-linkingcan be extended as the need arises. At the core, six key results arecontained, which are linked with the remaining results. The key resultsare represented on the sides of a cube. The schematic cuberepresentation shows how these key results hang together. All models canbe created (modeled) and documented individually. The essentialadvantage, however, lies in that two models joined by an edge can bevalidated by a third model, which is also joined by one edge each to thetwo other models. Consequently, an analysis of edges (relations) andalso nodes (objects) can be made. Thus any kind of information can bemodeled, documented and validated.

[0050] On the large cube 80, as also on the small cube 81, six modelsare to be seen. Process 82, element 82, information, function 84,business value chains 85, Product 86 and 87. Around this cube, resultssuch as quality assurance 88 and risk management 89 are represented,which are generated or derived by or from one or more of the otherresults (matrices, quality graphs and risk graphs). But there are alsoresults that influence all other results (strategy 810, requirements811) or have a simple relation. Along these relations an analysis ofeffects shall later be made.

[0051] The large cube 80 represents a complex system, e.g. a company, ata given instant in time (Slot), and the small cube 81 the same companyat another point in time. Between these two cubes 80, 81 a need foraction arises which can be assigned to concrete projects by means of aproject portfolio. The need for action can, for example, be generated indifferent ways by a merge & compare algorithm (optimal synergy, fewinterfaces, minimal change).

[0052] Regarding interrelations, the work product 87 plays an elementaryrole. A work product is an object characterized as an information andfunction container between two or more processes, elements, businessvalue chains etc. This means that objects are moved to and fro(interface object). A work product can be generated anywhere and canalso end again. A work product can also have a defined relation to aproduct.

[0053]FIG. 9 schematically shows work products on three different metalayers 90. 91, 92. The work product is one of the essential results ofthe inventive concept. On this result and its dependencies andprinciples on the one hand the process engineering and on the other handa part of the quality management are based. As a further point thecomprehensive risk management is to be mentioned, which is based on theinterplay of nodes (objects) and edges (relations). Between a workproduct and a product, and between work products among each other,uniquely expressible relations exist. These relations can also have aneffect over several different layers. These dependencies can be types,aggregates, compositions, or simple relations. By this view of resultsthat are used or generated in a company, and are modeled in anengineering step as work product, a net is produced. As alreadymentioned, with the aid of particular objects and the net, unequivocalstatements (e.g. quality, effect) can be made. These objects also carry,for the engineering and later for a workflow simulation, essentialinformation such as quantities, relative frequency, the manner oftransport (manual, electronically) or e.g. temporal behavior.

[0054]FIG. 10 simplifies the dimensions used. The approach shown ispartially based on the book “Der Objekt-Orientierte Weg” (OOW) by theapplicant (ISBN 3-9521597-0-0), mentioned above. In order to allowresults to be defined and positioned uniquely, for the sake of clarity adimension is omitted in the depiction of relationships. This was done bycombining the dimension methods/techniques with the dimensionresults/activities. Since methods and techniques mainly are related toresults and activities, the expressiveness is maintained to a largeextent. The fourth dimension, plans was put on the second dimension as areplacement of methods/techniques. The plan always is related to resultsand activities. Actually, in this dimension, only templates areconcerned. In these templates it is recorded which result sequences withwhat degree of detail lead to which total result and which activitiesare used therefore. In this approach it is also defined according to andwith which methods and techniques these results are worked out. Thethird dimension, architecture, remains unchanged. By this change theoverall information is maintained, but the complexity is significantlyreduced and the viewing and use is simplified.

[0055]FIG. 11 schematically shows a representation of strategy and goalseparation. One of the big advantages of the inventive concept consistsin that objects are placed into a relation to one another by means ofsimple rules. This principle is adopted from nature, where almost everyelement has a relationship to another one and can influence or beinfluenced through the relationship. If one properly views and definesthese mutual relationships, interesting aspects can be derived from theresults. First, by means of this interconnection, something can bestated about quality, and on the other hand a complete analysis ofeffects can be made. In order to have these statements actually be ofuse, they must be made very simple and defined uniquely. It must bedefined what the individual relationships signify, how they areconstructed and what effect they may have on others. If one masters thisnetwork of objects, that is, if one knows for each object the mostimportant information and partners, then with simple algorithmsessential statements with a high added value can be made. The algorithmsused are very simple. They are based on the rules of class/object,aggregation, compilation, inheritance, summation and probability. Asalready mentioned, the inventive concept is built up as a framework. Onthis basis it is possible to extend the models and definitionssubsequently shown anytime and without a large effort.

[0056] One strategy when influencing or leading a complex system, e.g. acompany, as a rule comprises different theses 110. Theses 110 can beinterrelated. These theses 110 can in turn again consist of theses or ofdifferent goals 111. The goals of a thesis are defined, qualified,quantified, are ordered, are prioritized, and can be interrelated. Theindividual goals of a thesis always add up to a hundred percent. Thissignifies that in addition to the properties already mentioned, also arelative and an absolute weighting of a goal within a thesis andstrategy exists. This is a consequence of the fact that the sum of alltheses of a strategy is one hundred percent as well. By means of apreference matrix 112, in addition to the absolute and relativeweighting, also a order can be determined and defined. According to thisdefinition, the individual goals or theses of other objects within theinventive concept are associated. This association can be with anexternal agent, process, element on the support level, a work product, arequirement etc. With these associations it can be defined as to howmany percent an object is affected by this strategy as well as to howmany percent a strategy depends on an object or is covered by an object.

[0057]FIG. 12 schematically shows how requirements 120 can be modeled.In order to successfully implement a strategy, requirements 120 must bedefined. These requirements are divided into e.g. functional, factual,time related, person related and/or social aspects. Then theserequirements are typified as quantifiable 121 and not quantifiable 122,such that they can be linked to other objects through a relation 123. Asalready described, there are different kinds of relations. Theconsequence of these kinds of relation is explained beneath.Requirements, just as goals, can be related to one another, defined,prioritized, sorted and associated with other objects. It thus isrelatively simple to find out, how and in which form requirements arelinked, how and what effects they can have on other objects.

[0058]FIG. 13 schematically shows the construction of a product model.In the book already mentioned “Der Objekt-Orientierte Weg”, henceforthcalled “OOW”, processes, business value chains, components and classesare described in detail. The definitions mentioned therein are adoptedin part in the following explanations.

[0059] For the processes the definition remains as supplied before. Thebusiness value chains are defined more clearly and put in a strongerrelation with other objects. See for this the description of the figures(chapter 9.2 and 10). The components described in the book “OOW” werefocussed strongly on developments in the field of IT. This focus wasextended by infrastructure, organization, electronical and mechanicalbuilding blocks and physical means. This layer is newly denoted as(process) support layer. Based on these extensions significantly morestatements can be made by the analysis of effects of this layer. Alsothe examination, expressiveness and rating of interfaces between thedifferent objects is enhanced by this extension. For reasons of clarityonly, the class layer was renamed as information and function layer.Nevertheless, the concepts of object orientation are appliedconsistently to all objects, but for clarity are designated differently.As new elements, the product, the strategy, the project portfolio andthe requirement have been added.

[0060]FIG. 13 schematically shows a product model, represented in asimplified manner as a mathematical model. The product model is a newapproach in the framework. In a product construction kit different kindsand parts of products and services are placed in relation to oneanother. A product class 131 therein represents a categorization ofproducts. These so-called combined products 132 can be assembled fromelementary products 133 and composite products 134 or from alreadydefined combined products 135. With these combined products a standardrate, a medium or a further property can be associated. These arepreferably represented by a class characteristic. Two representatives ofcombined products are known. The one is called product 136 and the otherservice 137. With this model any model of arbitrary complexity can beassembled or constructed. Of course, the objects goal and requirement asalready described, as well as others, can be linked with the individualparts of this construction kit.

[0061]FIG. 14 schematically shows a possible project management. Asalready mentioned, the project management is defined as a need foraction between two states. This principle is extended in the methoddiscussed here by a creation of scenarios and variants. In this contextone speaks of business improvement. The model is further complemented bythe link to the product model, which again allows a further manner ofperception. The models (process, element, information/function) definedon the different layers result in or represent a comprehensive state ofa complex system, e.g. a company. These states can be copied, extendedor reduced and represent either a scenario or a variation. By means ofan elaborate algorithm all differences on all levels and all objects canbe determined and represented as a change & compare list. This list withdifferences (delta list) represents the so-called need for actionbetween two states which then e.g. is assigned to a project and can beapplied to said project. The individual differences can then be assignedto results or templates (sum of results following each other, plan),which as a result corresponds to a project plan. This project plan makesvisible on the one hand results and also activities with which thedifference displayed can be worked out. Thus the inventive conceptallows to analyze, document and also validate effects from the strategyup to the concrete project. With this procedure it is possible tostandardize projects to a much higher degree, which in turn results in ahigher stability, re-usability and safety. With this approach risks inenterprise development can be reduced massively, the efficiency can beraised, effectiveness and profitability can be increased.

[0062]FIG. 15 schematically shows a possible form of quality management,The quality management in the disclosed concept is based on theinterconnection of objects. This networked approach allows to validatethe modeled and documented models. Under validation, the testing ofstates, process sequences and models by means of at least one furthermodel is understood. If, for example, the sum of all defined businessvalue chains is compared to the process model and its definition, aconclusion about the quality of the process model or the business valuechain can be made. Thus, the principle of quality assurance consists indetermining and showing the quality of a model by means of one or moreother models. Showing the quality can happen either in terms of acharacterizing number or by means of detail information.

[0063] One of the elementary objects considered is the business valuechain. A business value chain is a systematic sequence of events andactions. By extending the pure event/action approach by means of workproducts the possibility also arises to make a statement regarding thequality of e.g. a process. This rests on the basis that every input andoutput of a process is generated by means of a business value chain.

[0064] As represented in a matrix, on each side the processes arelisted, and in the corresponding cells the work product that is movedfrom one process to another process is entered. In this manner anoverview over all interface objects is obtained. If the same matrix isused to enter the work products used by a business value chain, acertain overlap can be seen. For a work product that does not show anoverlap, either the process definition or the definition of the businessvalue chain is incomplete. The same principle can also be extended overthe model layer, whereby again a conclusion about quality can bederived. In summary this means that the quality of a model always ischecked with one or more other models. With this method thecompleteness, the consistency, and conditionally also the correctness ofmodels can be checked. Furthermore it is shown in a very transparentmanner who uses what and when. In the case of correctness it is assumedthat it is higher if two independent definitions (models) lead to thesame result. This principle can also be applied over different modellayers and object types. For example, a business value chain on theprocess level and the same business value chain on the support level arecompared to one another. In this approach, by considering that theprocess and the supporting element are interlinked, a quality statementabout objects on different levels can be made. Implicitly, this can alsobe done for the quality of the business value chain itself.

[0065]FIG. 16 schematically shows a possible form of risk management.For calculating and propagating risks, in a simple representation, thefollowing principles apply. For each object 161, if necessary, one ormore risks 162 are defined. For each risk in turn a definition, e.g. aprobability of occurrence, a trend, a early warning indicator, net andgross risk, costs, one or more actions for avoiding the risk as well asbasis and dependencies of the risk itself, is defined. Thesedependencies can run along the network already defined, but can alsodefined in another manner. The computation of risks then is based on thenetwork and the percent distribution of the same. If one wishes todetermine the risk along a sequence (e.g. a business value chain), thenthe largest risk determined is considered as the risk of the entiresequence, as long as the influence always is positive and in the flowdirection. If further risks affect the sequence as influencing factors,then depending on the risk effect and direction, the risk value isdetermined. In this place one also speaks of risk appetite. With therisk appetite the sensitivity of an object to react to a risk isdescription. Depending on this network, later also the alarming is done.

[0066]FIG. 17 schematically shows dependencies that occur in theabstraction and creation of models. In a simplified representation thefundamental concept is based on three basic principles. First, on ameta-model, second on the basic principles of object orientation(encapsulation, inheritance, class/object etc.) and third on the idea ofnetworked thinking and acting. All objects stand in a definedrelationship to one another and comprise a clear definition. Regardingthe networking of the individual objects it is to be remarked that thereare relations that, according to the methodical approach, already existdepending of the object type (e.g. business value chain/work product,process/work product, process/element) and such that are entered by auser (e.g. goal/requirement, requirement/element). In the first case,the relations come into being by definition (by rule), in the secondcase it is defined, derived by the user (e.g. externalagent/requirement).

[0067] Each relation between two objects that is built by a user orcreated by the system can accept different definitions. Which definitionmakes sense can be determined by the user or is defined and/or limitedby the system, as they do not make sense. A process that is bases on amodel can for example only be decomposed. The process on the decomposedlevel for this reason is also called subprocess. A typification ofprocesses on the process model layer does not make sense at all. In theevent of a business value chain, it can be freely chosen whether thechild business value chain is a type or an aggregate, a decomposition orif it only stands in a relationship with the parent. If one generates asimple relationship (e.g. between risks), then in addition to thedirection, the influence (positive, negative) and the significance, alsothe weighting is to be defined. When the system carries outcalculations, then different results arise according to the relationshiptype. When, as an example, computations for a business value chain aremade, depending on the influence and direction, additions orsubtractions are carried out. If loops arise, factors are used incomputation. It is to be observed that there also are relationships forwhich a qualification does not make sense. (e.g. process/supportelement).

[0068]FIG. 18 schematically shows a comparison between work products andproducts. The work product and the product assume a special position inmodel creation. The work product and the product and also the workproducts among each other can stand in different relationships to oneanother. It is important that this interaction must be preciselydefined, such that no wrong information is derived from the modelscreated. In FIG. 18 some of these definitions that show how the existingmodels interact are assembled. This interaction can influence thequality management, the risk management and the cost management. It isimportant that a work product on different levels can be similar or, onthe other hand, very different. In an extreme case it can evencorrespond to a part of the product model or a product itself.Furthermore, a work product can also assume any defined form ofrelationship to another work product (aggregation, composition, etc.).Evidently, a work product as well as a product can assume differentstates. These states can be, for a work product order, e.g. order beingprocessed, order suspended, order completed. When modeling, this meansthat it is not necessary to create a dedicated work product for eachstate, but rather that only its property can be changed. This is animportant basis for reducing an immense variety of a work product. Whenworking with work products it is always important to know whether one istalking about a definition (order) or an instance (e.g. order by A).Normally, only the definitions are modeled. In this context it isimportant to note that states of a work product often are generated orchanged by a business value chain.

[0069]FIG. 19 schematically shows an analysis of effects. The networkdefined in model creation serves to analyze effects. Effects can notonly be computed along the relationships but also via states ofinterlinked objects. For example, each work product comprises at a givenmoment in time a specific state. The object has reached this state bycertain preconditions, rules, etc. This state can be changed by anevent. Via the relation to the product the product as well can bechanged implicitly. By defining during model creation, that a businessvalue chain in a simplified view is a value creation chain or part ofsuch, a relationship between a step of a business value chain an a workproduct comes into being. Since a step of a business value chain alwaysis associated with a process, a strong connection to the process arises.

[0070] If this basis is examined a little more closely, the states of awork product along a business value chain can represent a comprehensiveeffect on a product. From this and other derivatives from relationshipsequences, good and qualified statements regarding dependencies andeffects can be made very efficiently. This connection betweenproduct/work product and business value chain and the interpretation ofthis interaction is but one of many advantages of the approach chosen.

[0071]FIG. 20 schematically shows risks and their interrelations. Whenconsidering risks, as a rule, the same rules already mentioned furtherabove hold. On the one hand, the type of relationship is important, anthe other hand the influence is. Based on these two foundations riskscan be determined. By interlinking elements by the possibility that anobject may only correspond to a representation (aggregation) of severalother object, loops may also arise. These loops can influence overallrisks. This example is meant to show how difficult it is to computerisks. For this reason it is, as a rule, advantageous to create adependency diagram, such that the effects are also visuallyidentifiable.

[0072]FIG. 21 schematically shows a generation of scenarios andvariants. When a process landscape is built according to the modelingprocess explained above, an ideal support by systems can be createdaccording to different viewpoints. This creation of scenarios happens bythe application of different algorithms. In this, it is advantageous touse as few interfaces as possible. Ideal process support, ideal businessvalue chain support, small costs etc.

[0073] In FIG. 21 in a simplified manner a variant of such a generatedsolution is shown. The inventive approach in such generationsestablishes its own account models that can be compared by means ofmerge & compare. The individual solutions are created according topredefined best practices (patterns). Thus, theoretically possibleresults are excluded because of missing relevance to practice.

[0074]FIG. 22 in a simplified manner shows a cost management and thepreferably used computation algorithms used therein. Computations ofcosts are always based on the kind of network or the relationships. Ascan be seen from FIG. 22, e.g. the sum of three systems is computeddifferently, according to the kind of relationship. If the two childaggregates 221 are dependent of the parent aggregate 222 and the parentaggregate 222 itself has a value, then the value of the parent aggregateis the difference to the sum of the two child aggregates 221. If the twochild aggregates are of the type parent aggregate, then the value of theparent aggregate is irrelevant. However, if the two child aggregatesstand in a normal relationship to the parent aggregate, then all threevalues are added.

[0075] The costs on a element may be put composed in different ways. InFIG. 22 a possible subdivision is showed in a simplified manner. If e.g.it must be computed whether in a given period the available resourcesare sufficient, this can happen by accounting the available resourceswith the investments. By the fact that, as a rule, three differentrelationship sets exist, for each scenario a different value iscomputed. In one case, it works out even. In one case an over capacityand in the other an under capacity is computed.

[0076]FIG. 23 in a simplified manner shows different systems that standin relation to one another and support one or more processes. In theexample shown, the process is traversed by only one business valuechain, which in a practical application is rather an exception. In orderto compute the process costs, here the system costs are summedproportionally to the support percentage and shown as process costs.Addition is also performed when the degree of support is more or lessthan a hundred percent. Only when calculation is performed in theinverse direction, as a rule do differences get visible. In this case itis computed how much of the costs of a system can be allocated to whom.If a system does not support a process, then the costs are justdistributed over the business value chain. If the costs of all businessvalue chains are compared to the process costs, a difference (delta)arises according to this situation. The costs of a business value chainas a rule are computed from the percentage share of the process costs.If the case occurs that the sum of the business value chains is lessthan one hundred percent of a process, the value of the performance of aprocess will suffer a dramatic slump. Based on these simple calculationmodels already something significant can be said about the process costsand their origin.

[0077]FIG. 24 in a simplified manner shows a risk management and thecomputation algorithms used therein. For computing overall risks thereare different approaches. For example when considering the individualrisks shown in FIG. 24, several things can be derived. A typicalbusiness value chain, by not defining any own risks, on the processlevel becomes yellow. This is because sixty percent depend on a yellowprocess. It might also be red, since a hundred percent of the thirdprocess are supported by a red system and a positive dependency islisted. The business value chain on the system level clearly is red,since it passes through a red system. This is the case although the redsystem shows only an allotment of ten percent. The gross and net riskcosts arising from this situation can be determined according to thecost formula.

[0078]FIG. 25 in a simplified manner shows the dependencies betweenmultiple processes. Already in simple models very complex dependenciescan arise. For this reason it is important to visualize the dependenciesof risks and to discuss them, especially when trends and overall risksare involved. The example shown in FIG. 24 shows maximally two instancesof each object type. Nevertheless the risk is difficult to determinesince on the one hand strong dependencies and on the other hand loopsexist. For this reason, when computing risks over the dependencies,always the worst is used. We are conscious of the fact that then alwaysthe worst case is assumed.

[0079]FIG. 26 shows a reference model, FIG. 27 respectively shows areference model process. When in the context of the invention areference model is mentioned, this refers to an ideal state. Thereference model, for example, represents a standard solution in thefield of ERP. The solution builder (e.g. SAP) constructs his solutionalong the ideal state. In consequence, the supported processes, thedefined components as well as information maintenance and functionassignment are ideal. This basis, as a rule, creates problems during theconfiguration and introduction of a model in a complex system. If it isassumed that the model creation represents the ideal state and thesystem operator (e.g. manager, client) documents the current state, thenwithout much work it can be shown which integration scenario thesmallest effort results. Furthermore it can be shown where the riskslie, what costs arise and what changes in quality are to be expected.This procedure saves the system operator as well as the integrator hugeefforts during the analysis phase/design phase as well as theimplementation phase.

[0080] Any differences (delta) are determined by means of the same Merge& Compare algorithms that were already mentioned for application in thecreation of scenarios and variants. A mapping procedure is added, whichin a simplified manner is denoted as a glossary. With the help of thisglossary on the one hand definitions and on the other hand alsodifferent terms, definitions, models on different levels together can becompared. By means of this procedure it is not necessary to adapt thereference model to the customer state, but to construct itinteractively. Based on these results the system operator can quicklydefine the necessary migration project and show the effects.

[0081] A further advantage of this procedure consists in that e.g. acomplex system such as a company can be ideally transformed to animplementation date. The same principles can also be used for a releasemanagement. Before the implementation it is possible to show in a mostsimple manner what effects the new release will have on the currentstate. What functions are used or cannot/should not be used and who isaffected. By means of the same functionality, effects on clients can beanalyzed as well.

[0082]FIG. 28 shows different reports 281 that can be created accordingto the procedure described and the software that implements theprocedure. On one side lists and detail reports with relationships(links) of the individual elements can be generated. The documentationpreferably takes place in a text processing program such as Word, or inHTML or in a neutral format such as e.g. rich text format (rtf). Inthese formats all cross-references are output as well. Furthermore,matrix form representations are especially suited for documentation.Matrices are used mainly where the demonstration or analysis ofrelationships stands in the foreground. Furthermore, models can also beoutput in graphical form. Information can also be transferred to othertools. Thereby, preferably interfaces based on XML (extended markuplanguage), Flat-File, API or other database formats are used. Of course,bi-directional interfaces can be realized as well, if desired. Theseinterfaces preferably are based on a meta-model and are constructed andcreated according to the framework described.

1. A method for modeling, documenting and validating a system,preferably a company, comprising the following steps: 1) providing oneor more sensors in a system, 2) defining data to be recorded, 3)parameterizing the data to be recorded, 4) transforming theparameterized data to objects with parameters, 5) linking the parametersof the objects by standardized relationships, 6) checking and, ifrequired, completing or modifying the recorded ob to jects and theirparameters 7) recording the parameterized data by means of the sensors,8) standardized analysis of the relationships of the objects, 9)outputting the results of the standardized analysis in printed or inelectronic form, 10) repeating steps 3 through
 9. 2. The methodaccording to claim 1, wherein the steps 5 to 7 are repeatedperiodically.
 3. The method according to claim 1, wherein thresholdvalues for parameters are defined, which threshold values serve toinitiate an action.
 4. The method according to claim 1, wherein thesensors used are a software product installed on a computer, a mobiledevice or a user input device.
 5. The method according to claim 1,wherein the recorded data are business activities in an enterprise. 6.Computer software suited for executing the method steps according toclaim
 1. 7. Data carrier for computer software, which data carriercomprises a computer software according to claim 6.